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Description 

MR APPLICATION SAVE AND RESTORE 

SYSTEM 

Background of Invention 

[0001] The present invention relates generally to magnetic reso- 
nance imaging systems and tools. More particularly, the 
present invention relates to a system and method of stor- 
ing and restoring magnetic resonance applications. 

[0002] Several tools exist for the development of magnetic reso- 
nance (MR) imaging applications to be applied on an MR 
imaging system. The tools build a particular application 
environment through utilization and access to various 
system software components. Each component has asso- 
ciated tasks corresponding to MR categories, such as 
pulse sequencing, visualization, data processing, and im- 
age reconstruction. 

[0003] ^ is desirable to build new MR applications within a short 
period of time. In order to achieve rapid application devel- 
opment, visual tools based on JAVA™, exist to create vari- 



ous application developing environments. Components 
can be assembled or contained in new combinations using 
simple known drag-and-drop window techniques. Node 
connections are created between components with associ- 
ated linking information and each component may be re- 
configured with new parameter sets or property settings. 
As desired, the above-stated component and node con- 
nection features are performed without the need for the 
writing or compiling of new source code. 

[0004] | n order to reuse and execute a previously created appli- 
cation on an MR scanner, the application must have origi- 
nally been saved and must be restored. Commercial off 
the shelf mechanisms and formats for saving and restor- 
ing the applications do exist but unfortunately are inade- 
quate and performance limited. 

[0005] Current commercial saving and restoring mechanisms are 
only somewhat compatible with the existing MR imaging 
system software. Current commercial saving and restoring 
mechanisms in operation involve the traversing of a tree 
of components. The state of each component is either 
saved in a binary format, referred to as serialization, or 
the properties that have current values that differ from 
their default values are saved in an extensible markup 



language (XML) format, which is referred to as archiving. 
[0006] Serialization requires determining the version of the MR 

imaging software classes. During serialization, versions of 
the components are stored such that when new versions 
are created, files that were saved using a previous version 
cannot be restored due to incompatibility reasons. For ex- 
ample, when a restore is performed on an updated and 
saved application, in a new version of an application de- 
veloping platform, corresponding MR software for the new 
version is incapable of interpreting and recognizing any 
previously added or updated changes in the previous plat- 
form version. Serialization also suffers from not being 
supported in all Java classes, which are required in MR 
software. 

[0007] Archiving mechanisms have similar versioning and univer- 
sal class incompatibility issues, as that of serialization. 
Also, archiving techniques require traversing a hierarchy 
of components and comparing default settings of every 
object with current object settings to determine which ob- 
ject settings have been changed. This can take consider- 
able time. 

[0008] save and restore mechanisms that are capable of saving 
an updated application in a compatible MR imaging sys- 



tern format can lack the capability of performing any ad- 
ditional modifications, such as adding functions to a 
saved application. In order to perform additional modifi- 
cations to a previously updated and saved application the 
previous modifications and any new modifications need all 
be reentered. The reentering of modifications is undesir- 
able due to the repeated work steps and time involved 
therein. 

[0009] Thus, there exists a need for an improved system and 
method of saving and restoring MR applications that is 
compatible with existing MR imaging development soft- 
ware and allows for the building, reusing, modifying, sav- 
ing, and restoring of previously updated applications. 
Summary of Invention 

[0010] The present invention provides a system and method for 
saving and restoring applications for an imaging system. 
The method includes loading a developing environment. 
An initial application for the imaging system is loaded into 
or generated within the developing environment. The ini- 
tial application is modified to generate an updated appli- 
cation. The component and link modifications between 
the initial application and the updated application are 
saved. The updated application is then stored with the 



modifications in a tag file. The tag file is selected and the 
updated application is restored according to the tag file. 
[0011] The embodiments of the present invention provide several 
advantages over existing MR imaging application develop- 
ment tools. One such advantage that is provided by multi- 
ple embodiments of the present invention is the provision 
of a saving and restoring technique that is compatible 
with multiple existing development platforms and is not 
development platform version limited. The stated embod- 
iments allow for applications of various platform versions 
to be initialized, setup, used, modified, saved, and re- 
stored. 

[0012] Another advantage provided by an embodiment of the 

present invention is the allowance of an application to be 
modified, saved, and restored an indefinite amount of 
times without incurring extra overhead, due to the saving 
of the last modification to a property of a component 
rather than the accumulating of user edits that are redun- 
dant. 

[0013] Furthermore, another advantage provided by an embodi- 
ment of the present invention is the ability to perform 
easy and quick modifications to applications. An applica- 
tion may be modified within or external from an applica- 



tion developing environment. 

[0014] Moreover, yet another advantage provided by an embodi- 
ment of the present invention is the provision of an appli- 
cation save and restore system that is efficient at the 
loading and restoring of applications. 

[0015] The present invention itself, together with further objects 
and attendant advantages, will be best understood by ref- 
erence to the following detailed description, taken in con- 
junction with the accompanying drawing. 
Brief Description of Drawings 

[0016] Figure 1 is a cross-sectional and block diagrammatic view 
of a MR imaging system utilizing an application save and 
restore system in accordance with an embodiment of the 
present invention. 

[0017] Figure 2 is a block diagrammatic view of the application 
save and restore system in accordance with an embodi- 
ment of the present invention; and. 

[0018] Figure 3 is a logic flow diagram illustrating a method of 

saving and restoring an application for the MR imaging 

system of Figure 1 in accordance with an embodiment of 

the present invention. 
Detailed Description 



[0019] | n eacn of the following figures, the same reference nu- 
merals are used to refer to the same components. While 
the present invention is described with respect to a sys- 
tem and method of storing and restoring magnetic reso- 
nance developed applications, the present invention may 
be adapted for various systems including magnetic reso- 
nance imaging (MRI) systems, computed tomography (CT) 
systems, radiotherapy systems, X-ray imaging systems, 
ultrasound systems, nuclear imaging systems, magnetic 
resonance spectroscopy systems, or other system known 
in the art. Also, the present invention may be applied to 
various applications in various fields of endeavor. 

[0020] | n the following description, various operating parameters 
and components are described for one constructed em- 
bodiment. These specific parameters and components are 
included as examples and are not meant to be limiting. 

[0021] Referring now to Figure 1, a cross-sectional and block di- 
agrammatic view of a magnetic resonance (MR) imaging 
system 10 utilizing an application save and restore system 
12 in accordance with an embodiment of the present in- 
vention is shown. The MRI system 10 includes a static 
magnet structure 11 (a cylindrical structure) and a signal 
processing system 13. The signal processing system 13 is 



coupled to the magnet structure 11 and reconstructs an 
image for a region-of-interest of a patient in response to 
radio frequency magnetic resonance signals, as further 
described below. The application system 12 is coupled to 
several devices of the imaging system 10 and is used in 
the creating, developing, saving, and restoring applica- 
tions. The applications are loaded within the application 
system 12 and are used in the control of the imaging sys- 
tem 10. The application system 12 is described in detail 
below with respect to the embodiment of Figure 2. 

[0022] The static magnet structure 11 includes a superconduct- 
ing magnet 16 having multiple superconducting magnetic 
field coils 17, which generate a temporally constant mag- 
netic field along a longitudinal axis (z-axis) of a central 
bore 18 (patient bore). The superconducting magnet coils 
17 are supported by a superconducting magnet coil sup- 
port structure 20 and are received in a toroidal helium 
vessel or can 22. 

[0023] a main magnetic field shield coil assembly 24 generates a 
magnetic field that opposes the field generated by the su- 
perconducting magnet coils 17. A toroidal vacuum vessel 
26 includes a cylindrical member 28 that defines the pa- 
tient bore 18 and extends parallel to a longitudinal axis 



30. On a first exterior side 32 of the cylindrical member 
28, which is the longitudinal side farthest away from the 
axis 30, is a magnetic gradient coil assembly 34. 

[0024] The patient bore 18 has a RF coil assembly 36 (antennae) 
mounted therein. The RF coil assembly 36 includes a pri- 
mary RF coil 38 and a RF shield 40. 

[0025] The signal processing system 13 includes a RF transmitter 
42 that is coupled to a sequence controller 44 and the 
primary RF coil 38. The RF transmitter 42 is preferably 
digital. The sequence controller 44 controls a series of 
current pulse generators 46 via a gradient coil controller 
48 that is connected to the magnetic gradient coil assem- 
bly 34. The RF transmitter 42 in conjunction with the se- 
quence controller 44 generates a series of spatially lo- 
cated radio frequency signals or encoded magnetic field 
gradient pulses. The gradient pulses are applied across a 
region-of-interest within the magnetic field for exciting 
and manipulating magnetic resonance in selected dipoles 
of the region-of-interest, such as a portion of a patient 
within the patient bore 18. 

[0026] a radio frequency receiver 52 is connected with the pri- 
mary RF coil 38 for the demodulation of magnetic reso- 
nance signals that emanate from an examined portion of 



the subject. An image reconstruction apparatus 54 recon- 
structs the received magnetic resonance signals into an 
electronic image representation that is stored in an image 
memory 56. A video processor 57 converts the stored 
electronic images into an appropriate format for the dis- 
play on a first monitor 58. The reconstructed image may 
be observed by the operator on the display 58, as well as 
other data from the restoring system 12. 

[0027] Referring now to Figure 2, a block diagrammatic view of 
the application system 12 in accordance with an embodi- 
ment of the present invention is shown. The application 
system 12 includes a scanner user interface 60 and a de- 
veloper user interface 62, both of which may be consid- 
ered application controllers. 

[0028] The scanner interface 60 is coupled to and controls oper- 
ation of the signal processing system 13. Applications 
may be loaded by the scanner interface 60 and executed. 
The scanner interface 60 receives commands and scan- 
ning parameters, via an input device 64, which are used in 
operation of the system 10. 

[0029] The developer interface 62 is used for the development of 
various imaging system applications. Although the scan- 
ner interface and the developer interface are shown as 



separate interfaces, they may be combined into a single 
interface. The single interface may be coupled to the sig- 
nal processing system 13 and perform both operation and 
development tasks. Also, although a single scanner inter- 
face and a single developer interface are shown, any num- 
ber of each may exist within the application system 12. 

[0030] The scanner interface 60 and the developer interface 62 
may be microprocessor based, such as a computer having 
a central processing unit, memory (RAM and/or ROM), and 
associated input and output buses. The scanner interface 
60 and the developer interface 62 may be a portion of a 
central or main control unit or may each be stand-alone 
components as shown. 

[0031] The scanner interface 60 is coupled to the input device 64 
and the first monitor 58. The developer interface 62 is 
coupled to a modification interface 66 and a second mon- 
itor 68. The input device 64 and the modification interface 
66 may be in the form of a keyboard or a mouse, by which 
an operator may operate, generate, modify, save, upload, 
and restore imaging system applications, as well as per- 
form other tasks known in the art. The input device 64 
and the modification interface 66, although are described 
as being hardware based, may be software based. By be- 



ing software based other system control methods, known 
in the art, may use the input device 64 and the modifica- 
tion interface 66 to generate various signals correspond- 
ing to the above stated tasks. 

[0032] The scanner interface 60 and the developer interface 62 
may be located at a single location or may be at separate 
locations. For example, the scanner interface 60 may be 
located at a customer site and the developer interface 62 
may be located at a manufacturer site. 

[0033] The scanner interface 60 and the developer interface 62 
have access to a first memory 72, which has stored appli- 
cation tag files 74. The tag files 74 may be structured 
files. The tag files are in an extensible markup language 
(XML) text file format or the like having the latest modifi- 
cations for a current session. The tag files 74 may be dig- 
itally signed or password protected to prevent unautho- 
rized modification of the tag files 74. The tag files allows 
a user to directly read a particular tag file and perform 
edits. The tag files also allow for restoring and editing of 
files without being dependent on application classes, such 
as prior art methods that utilize serialization. 

[0034] The first memory 72 may be located at a central location, 
at the site of the scanner interface 60, at the site of the 



developer interface 62, or may be divided into separate 
memories having similar contents. The interfaces 60 and 
62 may access the first memory 72 via a wired connec- 
tion, a wireless connection, a network, an Internet, an In- 
tranet, or via some other connection known in the art. 
[0035] The first memory 72 stores the latest application modifi- 
cations and linking information for the various application 
components. The application components may be contin- 
uously stored and may be of various types and styles, as 
known in the art. The application components may apply 
to pulse sequencing and data processing, to visualization 
and image reconstruction, or to other imaging system 
categories known in the art. The linking information in- 
cludes information, such as the manner as to which com- 
ponents are coupled or interlinked. The linking informa- 
tion also includes parameter or property types that are 
transferred between components, such as various input 
and output values or signals that may be performed in a 
particular order, used from one component to the next, or 
between multiple components. For example, a Fast Fourier 
Transform (FFT) component may be coupled to a phase 
component and output from the FFT component may be 
used as an input to the phase component. 



[0036] The developer interface 62 also has access to a second 
memory 70, which stores a framework or application 
component list 71. The application component list 71 in- 
cludes the available components that may be used to cre- 
ate and develop a desired application. As new compo- 
nents become available they are added to the application 
component list 71. The scanner interface 60 may have ac- 
cess to the second memory 70, such as when the scanner 
interface 60 and the developer interface 62 are incorpo- 
rated into a single interface. 

[0037] The scanner interface 60 may be software based and have 
various operating windows (not shown), some of which 
may contain various components and software modules 
for performing desired system operating tasks. The scan- 
ner interface 60 includes an application operating envi- 
ronment 76 that includes a scanner application loader 78 
and a current scanner application 80. The scanner appli- 
cation loader 78 is used to load and restore a desired ap- 
plication. When the desired application is in the form of a 
tag file 74, the scanner loader 78 uses a tag file loader 82 
to retrieve the appropriate tag file from the first memory 
72. 

[0038] The scanner application 80 includes an application com- 



ponent organizational chart or application component tree 
84 that has multiple application components 86 that were 
originally selected from the application component list 71. 
The application tree 84 has a hierarchal design that corre- 
sponds to the manner as to which the components 86 are 
linked. The hierarchial design refers to the order that the 
components 86 and corresponding tasks are performed 
and the interdependent relationships between the compo- 
nents 86. The application tree 84 has a first application 
component or application container 88 and subordinate 
application components 90 extending therefrom. The ap- 
plication tree 84 may be of various sizes and have any 
number of application components. Each application com- 
ponent 86 may have any number of application compo- 
nents extending therefrom. Although the application 
components 86 are shown as being organized in the form 
of an application component tree, the application compo- 
nents 86 may be organized using some other organiza- 
tional technique known in the art. 
[0039] The developer interface 62 includes an application devel- 
oping environment 92, which may also be software based 
and have various operating windows (not shown), some of 
which contain various components, and software modules 



for performing desired development tasks. The applica- 
tion developing environment 92 may be used to modify 
the application component list 71 and the components 
within the list 71. The developer interface 62 may receive 
modification signals from the modification interface 66 
and in response thereto modify the application compo- 
nent list 71, the components within the list 71, and any 
corresponding linking information between the compo- 
nents. The developer interface 62 may add components to 
or remove components from the application list 74, 
change arrangement of the components, change linking 
information between the components, or perform some 
other component modification known in the art. 
[0040] The developing environment 92 includes a developer ap- 
plication loader 94, a tag file generator 96, multiple edi- 
tors 98, an application modification list 100, and a current 
developer application 102. The development loader 94 in- 
cludes a component loader 104 and a tag file loader 106, 
which is similar to the tag file loader 82. The component 
loader 104 is utilized to load a component in the compo- 
nent list 74 into the developing environment 92. The tag 
file loader 106 may be utilized to restore a previous appli- 
cation. The tag file loader 106 restores a previous appli- 



cation according to an associated tag file 74. The devel- 
oper loader 94 may open and modify a corresponding de- 
fault application, generate an application according to the 
tag file, or generate an application utilizing components 
from the application component list 71. The developer 
loader 94 also resets any properties or values generated 
by the custom property editor 108 or from the standard 
property editor 110, as stored in the tag file 74. 

[0041] The tag file generator 96 generates and stores the tag 
files of the updated applications, with the component 
modifications and corresponding component linking in- 
formation, in the first memory 72. The application system 
12 stores the component related information in a tag file 
and in so doing provides flexibility in performing devel- 
opment application modifications. 

[0042] The editors 98 include the custom property editor 108, 

the standard editor 110, and the text editor 112. The cus- 
tom property editor 108 is used to perform custom edits 
to an application component. The custom property editor 
108 generates custom values such as a value of a param- 
eter not normally used. The custom property editor 108 is 
used for properties, which are not standard Java types (int, 
char, etc.) or custom data types. The custom data types 



may include data or values that are not custom in nature. 
The developer interface 62 stores the custom values as 
they are generated in the application modification list 
100. The standard editor 110 is used to perform various 
normal or standard modifications to an application com- 
ponent using standard datatypes. 
[0043] The text editor 112 is used to directly perform edits to an 
application component's property tags. A tag file may be 
modified within or external from the developing environ- 
ment 92. In other words, an application component of in- 
terest may be modified using the developing environment 
92 or may be modified by simply opening and modifying 
the tag file without initializing or executing the develop- 
ing environment 92. When a small quantity of modifica- 
tions are to be performed, external modification to the tag 
file may be desired, since it provides increased efficiency 
and ease in modifying and developing an application. 
Also, the tag file allows an operator to view the modifica- 
tions that have been performed by simply reviewing con- 
tents of the tag file. The application component may be 
viewed in a text format and code or values therein may be 
quickly and directly changed. In one embodiment of the 
present invention, the text editor 112 is used to perform a 



quick value change. The text editor 112 is used to view 
and change the value within a specific application compo- 
nent. The application component is viewed in the text edi- 
tor 112 without uploading or restoring an entire applica- 
tion. 

[0044] The application modification list 100 is a list of the latest 
application modifications that have been performed for 
the application components in the developer application 
102. As application components or linking information are 
modified the modification list 100 is modified as to the 
changes, which is explained in further detail below. The 
modification list 100 may be stored in the first memory 
72, the second memory 70, or in some other computer or 
designated memory. 

[0045] The developer application 102 as with the scanner appli- 
cation includes a component tree 114 that has multiple 
application components 116. The component tree 114 has 
a first application component or application container 118 
and subordinate application components 120 extending 
therefrom. The component tree 114 may be of various 
sizes and have any number of application components. 
Each application component 120 may have any number of 
application components extending therefrom. Although 



the application components 120 are shown as being orga- 
nized in the form of an application component tree, the 
application components 120 may be organized using 
some other organizational technique known in the art. 

[0046] Referring now to Figure 3, a logic flow diagram illustrating 
a method of saving and restoring an application for the 
MR imaging system 10 in accordance with an embodiment 
of the present invention is shown. 

[0047] | n step i3o j the developer interface 62 loads the develop- 
ing environment 92. 

[0048] | n s tep 132, the developer loader 94 loads an initial appli- 
cation in the developing environment 92. The developer 
loader 94 loads and initializes a development application 
as selected by an operator. The initial application has one 
or more components that are in an initial component state 
with initial values and settings, which may be different 
than that of corresponding default values and settings. 
For example, the initial application may have one or more 
components that have been modified or stored previously 
with values and settings that are different from their de- 
fault values and settings. 

[0049] in step 134, an initial application is generated in response 
to input signals that are generated from the modification 



interface 66. The operator may generate a new application 
using components from the application list 74. 

[0050] | n s tep 136, the operator, via the modification interface 
66, or the developer interface 62 generates modification 
signals to alter the initial development application. Com- 
ponents within the application list 74 may be added, re- 
moved, modified, or repositioned using various tech- 
niques known in the art. 

[0051] | n s t e p i33 j the developer interface 62 in response to the 
modification signals modifies the initial application to 
generate an updated application. 

[0052] in step 140, as modification signals are generated and 

components and link information are modified, the devel- 
oper interface 62 stores the modifications in the modifi- 
cation list 100. The systematic storing of the modifica- 
tions as they are entered or enacted saves time in storing 
of an updated application. A modification is saved when it 
is different than a current value or setting. Previous modi- 
fications of the same property are discarded as changes 
are made to that property. 

[0053] Certain values may not be saved and later restored. These 
values may be used solely during the development of an 
application, such as a value prescribed on the developer 



interface 62 of the application. Prescribing a development 
application may be done during the building of an appli- 
cation for test purposes, but since the prescription is not 
actually part of the application it is not saved. 

[0054] | n step 142, when desired modifications have been per- 
formed the tag file generator 96 saves the updated appli- 
cation with the modifications in a generated tag file. The 
updated application is stored quickly since the modifica- 
tions are stored as they are performed and no compar- 
isons between the initial application and the updated ap- 
plication need be performed. 

[0055] The tag file generator 96 in storing the updated applica- 
tion stores general multiversion identifiers associated with 
each component. Through the use of multiversion identi- 
fiers, the present invention is not version limited, as ap- 
plication saving and restoring methods of prior art. The 
multiversion identifiers identify general components by 
name without use of version identification numbers. The 
developer interface 62 when initializing an application as 
in steps 132 and 134 searches for a component in mem- 
ory having the multiversion identifier and initializes that 
component. 

[0056] | n s tep 144, the tag file may be edited to modify the up- 



dated application external from the developing environ- 
ment 92. The tag file may be edited using the text editor 
112, as described above. 
[0057] | n s t e p i45 j the scanner interface 60 or the developer in- 
terface 62 restores the updated application according to 
the tag file. After the updated application has been stored 
it may be accessed and restored by either the interface 60 
or the interface 62. The tag file is read and the stored up- 
dated application is constructed in the operating environ- 
ment 76 or in the developing environment 92 with prop- 
erty settings and node connections of the application 
components, as stated in the tag file. The updated appli- 
cation with the modifications when restored is in the same 
state as when it was originally created or modified, as in 
steps 130-142. 

[0058] | n s tep 148, upon restoration of the updated application 
an operator may utilize the updated application, in the 
operating environment 76, to control the operation of the 
imaging system 10. 

[0059] in step 150, the updated application may be further modi- 
fied, within the developing environment. This is unlike de- 
velopment application store and restore techniques of 
prior art in which stored files are unable to be modified to 



add new functionality. 

[0060] The present invention performs the above save and re- 
store techniques using the developer interface 62 without 
separately generating or writing source code. 

[0061] The above-described steps in the above methods are 
meant to be an illustrative example; the steps may be 
performed sequentially, synchronously, continuously, or 
in a different order depending upon the application. 

[0062] The present invention saves and restores applications in 
such a manner as to allow for the modification of restored 
applications without being version limited. The present 
invention decreases development time, since previously 
modified applications may be restored and further modi- 
fied. The present invention also provides increased versa- 
tility and efficiency in performing the modifications 
through use of a tag file. 

[0063] The above-described apparatus and method, to one 

skilled in the art, is capable of being adapted for various 
applications and systems known in the art. The above- 
described invention can also be varied without deviating 
from the true scope of the invention. 



